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LLP 

(57) ABSTRACT 

A method for enabling enhanced call return in a wireless 
network comprising receiving an incoming telephone call 
from a caller, wherein the incoming telephone call identifies 
a mobile subscriber (MS) as a callee thereof; capturing 
caller-specific information for the caller, wherein the caller- 
specific information includes at least one of the name of the 
caller and the telephone number of the caller; and storing the 
caller-specific information into an intelligent peripheral (IP) 
within the wireless network. The method further comprises 
allowing the MS to access the caller-specific information 
stored in the IP. The present invention thus allows the mobile 
subscriber (MS) to subscribe to an enhanced call return 
(ECR) feature as part of the mobile telephone service plan. 
The ECR feature allows the mobile subscriber to access 
caller-specific information for a predetermined number of 
past callers and also to return calls from those past callers. 
The caller-specific information may include caller's name, 
caller's telephone number and the date/time the call was 
received from the caller. 

40 Claims, 21 Drawing Sheets 
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ENHANCED CALL RETURN IN A WIRELESS 
TELEPHONE NETWORK 

I. CROSS REFERENCE TO RELATED 
APPLICATIONS 

(Not Applicable) 

n. STATEMENT REGARDING FEDERALLY 
SPONSORED RESEARCH OR DEVELOPMENT 

(Not Applicable) 

III. BACKGROUND OF THE INVENTION 

1. Field of the Invention 

The present invention relates to wireless communication 
systems and, more particularly, to an implementation of an 
enhanced call return feature in a wireless telephone network. 

2. Description of the Related Art 

Contemporary telephone subscriber services may be 
divided into two major categories: (1) Wire line services; 
and (2) Wireless services. A wire line service typically 
utilizes a wired network of telephone cables or conductors. 
In other words, in a wire line network, telephone signals are 
transmitted over a physical wire path of, typically, copper 
conductors or wires. On the other hand, wireless services 
/ (e.g., cellular telephone service, personal communications 
service (PCS), etc.), as the name suggests, employ wireless 
means to carry telephone signals through the air (i.e., instead 
of wires) between a caller and callee. Although a telephone 
call originating in a wireless network may ultimately be 
transmitted through a wire line network to reach its 
destination, the principal mode of communication nonethe- 
less still remains wireless in the wireless network. Typical 
examples of wire line telephone networks include the POTS 
(Plain Old Telephone System) and the more advanced PSTN 
(Public Switched Telephone Network). Some examples of 
land-based wireless telephone networks include the cellular 
(or mobile) telephone network and the personal communi- 
cations network (PCN), 

Both of the above-mentioned subscriber telephone ser- 
vices are governed by a number of corresponding regulatory 
standards and protocols that define how calls are to be 
treated in the respective system and which subscriber ser- 
vices may be provided. Some wire line service standards and 
protocols include the AIN (Advanced Intelligent Network) 
standard which may be considered as an upgrade to the SS-7 
(signaling system number 7) standard, and the Internet 
Protocol (IP) for Internet-based telephony. Wireless tele- 
phone communication is also governed by a number of 
different standards and protocols, including the second gen- 
eration TDMA(Time Division Multiple Access) air interface 
standard (popularly known as the IS-136 standard) and the 
wireless intersystems operation standard (alternately 
referred to as the IS-41 or the TIA/EIA-41 standard), both of 
which may be considered part of the WIN (Wireless Intel- 
ligent Network) standards. 

The AIN protocol for the wire line network allows a 
telephone service provider to offer a variety of service 
options to a telephone line subscriber. Some of the services 
that may be offered by a telephone service provider include 
the telephone number portability service, the calling name 
service, the voice mail service, and the call return service. 
The call return feature allows a user (i.e., telephone line 
subscriber) to dial an access code, e.g., *69, to place a call 
to the calling party that last called the user's telephone 
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number. This service is useful in a number of situations, e.g., 
when the calling party hangs up without giving the user a 
chance to pick up the phone, or when the user is aware of the 
phone call but unable to reach the phone and the calling 
s party does not leave any message for the user. 

Presently, a similar call return feature is absent for the 
subscribers of wireless telephone services. It is therefore 
desirable to implement the call return feature in wireless 
telephone networks. 

10 

IV. SUMMARY OF THE INVENTION 

The present invention contemplates a method for enabling 
enhanced call return in a wireless network comprising 

1S receiving an incoming telephone call from a caller, wherein 
the incoming telephone call identifies a mobile subscriber 
(MS) as a callee thereof; capturing caller- specific informa- 
tion for the caller, wherein the caller-specific information 
includes at least one of the name of the caller and the 

2 q telephone number of the caller; and storing the caller- 
specific information into an intelligent peripheral (IP) within 
the wireless network. The method further comprises allow- 
ing the MS to access the caller-specific information stored in 
the IP. 

25 The present invention further contemplates a wireless 
communication system comprising a line information data 
base (LIDB) configured to store caller-specific information 
therein, wherein the LIDB receives the caller-specific infor- 
mation when a caller originates a telephone call that iden- 

30 tifies a mobile subscriber as a callee thereof; an originating 
mobile switching center (MSC) configured to receive the 
telephone call and to generate a first message in response 
thereto; a home location register (HLR) coupled to the 
originating MSC, wherein the HLR is configured to receive 

35 the first message and to responsively retrieve one or more 
parts of the caller-specific information from the LIDB; and 
an intelligent peripheral (IP) coupled to the HLR, wherein 
the HLR is configured to transfer the one or more parts of the 
caller-specific information to the IP via a second message 

40 from the HLR to the IP. 

The present invention allows the mobile subscriber (MS) 
to subscribe to an enhanced call return (ECR) feature as part 
of the mobile telephone service plan. The ECR feature 
allows the mobile subscriber to access caller-specific infor- 
ms mation for a predetermined number of past callers. The 
caller-specific information includes the caller's name, the 
caller's telephone number and the date/time the call was 
received from the caller. The MS may scroll the list of callers 
whose data are stored in the subscriber's mailbox in the IP 

50 to determine which caller(s) to return the call(s) to. The 
interaction between the MS and the IP may be voice- 
activated. While "talking" to the IP, the mobile subscriber 
may choose a specific caller to place a call to, or, alternately, 
the mobile subscriber may simply end the inquiry, albeit 

55 with the knowledge of who called that subscriber in the 
recent past. 

V. BRIEF DESCRIPTION OF THE DRAWINGS 

6Q Further advantages of the present invention may be better 
understood by referring to the following description taken in 
conjunction with the accompanying drawings, in which: 

FIG. 1 shows a prior art wireless network reference model 
representing an interconnection of the network entities 
65 required to implement the enhanced call return feature; 
FIG. 2 depicts a prior art IS-41 messaging for a mobile 
subscriber registration process in a wireless network; 
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FIGS. 3-4 illustrate exemplary message formats for the 
prior art messages shown in the registration process depicted 
in FIG. 2; 

FIG. 5 shows an exemplary sequence of IS-41 messages 
that may be used to store caller-specific information in a 
mailbox created in the intelligent peripheral (IP) for the 
called party (i.e., the mobile subscriber); 

FIGS. 6-14 illustrate exemplary message formats for the 
prior art messages used in the sequence of messages shown 
in FIG. 5; 

FIG. 15 illustrates an exemplary messaging scheme 
whereby a modified SRFDIR Invoke message may be uti- 
lized to allow a mobile subscriber to interact with the IP to 
retrieve the call return information from the subscriber's 
mailbox in the IP; 

FIGS. 16-20 illustrate exemplary message formats for 
some of the prior art messages used in the sequence of 
messages shown in FIG. 15; 

FIG. 21 shows an exemplary message format for the 
SRFDIR Invoke message; and 

FIGS. 22-24 illustrate exemplary message formats for the 
remainder of the prior art messages used in the sequence of 
messages shown in FIG. 15. 

VI. DETAILED DESCRIPTION OF PREFERRED 
EMBODIMENTS 

Referring now to FIG. 1, a wireless network reference 
model 10 representing an interconnection of the network 
entities (NEs) required to implement the enhanced call 
return feature is illustrated. The network reference model 10 
appears in Chapter-1 (or Part-1) of revision-D of the IS-41 
(Interim Standard -41) wireless intersystem operation stan- 
dard. The revision-D of the IS-41 standard is incorporated 
herein by reference in its entirety. Copies of the most recent 
revision (and/or earlier revisions) of the IS-41 standard may 
be obtained from the Global Engineering Documents, 15 
Inverness Way East, Sales-C303B, Englewood, Colo., USA 
80112-9649. 

The IS-41 standard is more recently referred to as a 
TIA/EIA-41 standard, where 'TLA stands for Telecommu- 
nications Industry Association and 'EIA' stands for Elec- 
tronics Industry Association. However, the following dis- 
cussion uses the designations IS-41 and TIA/EIA-41 
interchangeably. Further, the term "wireless network" as 
used herein is contemplated to include analog or digital 
cellular mobile networks (irrespective of the underlying 
digital technology, e.g., CDMA, TDMA, etc.) and any other 
radio network that employs intersystem messaging (IS-41 
based or not) as part of mobile wireless communication. 
Although the discussion herein focuses on IS-41 messages 
to accomplish enhanced call return in a wireless network, it 
is understood that the methodology described herein may be 
implemented with other non-IS-41 messages that may be 
functionally similar to those described hereinbelow. 

It is known in the art that IS-41 is the technical standard 
that specifies the network model, functions, protocols, and 
services that provide mobile telecommunications networks 
intersystem operations. The IS-41 specification provides a 
standard protocol for the operations that enable subscriber 
mobility between two MSCs (Mobile Switching Centers) in 
a single wireless network or in two different wireless net- 
works operated by a single or two different service provid- 
ers. In other words, the IS-41 standard specifies the neces- 
sary signaling mechanism to accomplish seamless 
communication in the mobile world. A brief description of 
each of the network entities is given below. 
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The network entities (NEs) in FIG. 1 include an anchor 
mobile switching center (MSQ 12, a visiting (or serving) 
MSC 14, a public switched telephone network (PSTN) 18, 
an intelligent peripheral (IP) 20, a service control point 

S (SCP) 22, a home location register (HLR) 23, a visitor 
location register (VLR) 24, and a line information database 
(LJDB) 26. These network entities represent functional 
blocks or units that perform various logical functions that 
are implementation-independent. In other words, one or 

10 more of the above-mentioned network entities may be 
constructed in different physical configurations by different 
mobile service providers and, hence, the model shown in 
FIG. 1 does not imply either a specific physical implemen- 
tation of a network entity shown therein or a specific 

15 interconnection between two or more network entities 
shown therein. For example, the discussion given hereinbe- 
low identifies the VLR 24 as associated with the anchor 
MSC 12 as well as with the serving MSC 14. However, the 
diagram in FIG. 1 does not show a direct physical intercon- 

2Q nection between the VLR 24 and the serving MSC 14. The 
sharing of the VLR 24 may be possible, for example, when 
both of the mobile switching centers 12, 14 are operated by 
a common service provider. 

It is therefore emphasized that the arrangement shown in 

25 FIG. 1 is for illustration only. The network entities shown in 
FIG. 1 may not represent actual physical connection, espe- 
cially when call-routing involves many more cells and, 
hence, many more network entities, in a wireless network. 
For example, in one embodiment, the serving MSC 14 may 

30 have its own HLR and VLR (not shown) and may be 
maintained by a service provider that is different from the 
service provider maintaining the anchor MSC 12 and its 
associated network entities. In short, the network topology 
in FIG. 1 is a symbolic representation of various functional 

35 blocks comprising a wireless network and does not imply a 
fixed, physical implementation of those functional blocks. A 
service provider may choose not to provide all the network 
entities or all the interconnections illustrated in FIG. 1 in a 
given geographic area or cell. Further, more than one 

40 functional unit may be implemented on a single physical 
device, or, alternatively, some functional blocks may repre- 
sent separate physical devices. For example, the IP 20 may 
be a part of the HLR 23, which, may also include the SCP 
22 when all of these functional units are physically imple- 

45 mented. On the other hand, the MSC 12 and the LIDB 26 
may each be built as separate physical devices. 

Each network entity is shown interconnected via inter- 
faces represented by different interface reference points. For 
example, the anchor MSC 12 and the visiting (or serving) 

50 MSC 14 are shown connected via the interface reference 
point 'E*, and the anchor MSC 12 and its associated HLR 23 
are shown connected via the interface reference point 'C. 
Other interface reference points are also illustrated in FIG. 
1. These interface reference points represent the point of 

55 connection between two adjacent physical or logical net- 
work entities. A point of connection is defined by functional 
and signaling characteristics and may define the operational 
responsibility of the interconnected network entities. Thus, 
the signaling characteristic of the B interface may be dif- 

60 ferent from that of the T a interface, and the signaling 
characteristic of the C interface may be different from that 
of the D interface, etc. 

It is noted that the terms "mobile subscriber", "network 
subscriber" and "mobile user" are used interchangeably 

65 hereinbelow. A "mobile subscriber (MS)" (not shown) may 
be a human individual who has subscribed to one or more 
mobile wireless services. The term "mobile subscriber", as 
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used herein, also includes a mobile service user who uses the 
subscribed wireless service(s) with a mobile telephone hand- 
set or with a computer equipped for wireless communication 
or with any other similar device. Further, "mobile commu- 
nication" may include voice, data or any other information 
communicated via a mobile wireless network. 

A mobile switching center (MSC) is a functional entity 
that represents an automatic wireless message switching 
system. An MSC may be distinguished from an MTSO 
(mobile telephone switching office), which may refer more 
to the physical architecture of the wireless switching office 
including switching hardware, the physical building, etc. An 
MSC typically provides interface for user traffic between a 
cellular network and other public switched networks 
(PSTNs) or other MSCs in the same or other networks. An 
MSC provides basic switching functions and coordinates the 
establishment of calls to and from cellular subscribers. Thus, 
an MSC is responsible for various call processing as well as 
mobile subscriber mobility management functions. 

An MSC first receiving a call placed by a caller (calling 
a mobile subscriber) may be referred to as the "anchor 
MSC (e.g., the MSC 12), whereas an MSC that finally 
delivers the call to the mobile subscriber (and thus com- 
pletes the call) may be referred to as the "serving MSC 
(e.g., the MSC 14). The geographic location of the mobile 
subscriber (MS) at the time of call reception (from the 
external telephone network, e.g., the PSTN 18 or other 
wireless network) determines whether the anchor MSC 12 
and the serving MSC 14 are the same or different. 

The functional block labeled "PSTN" 18 may include an 
external wire line telephone network carrying a call from an 
external network caller to a mobile subscriber (MS) (not 
shown) or vice versa. The A,- interface represents an inter- 
connection between the PSTN 18 and a switching center in 
the mobile network, here, the MSC 12. The PSTN 18 may 
include a digitally switched telephone network, the POTS 
(plain old telephone system), the Internet or other external 
networks, including a local area network (LAN) or other 
dissimilar mobile network. It is known that mobile networks 
usually intemperate with other networks (e.g., the PSTN 18) 
to complete calls. 

The intelligent peripheral (IP) 20 may be a server or any 
other database capable of creating and storing "mailboxes" 
for those mobile subscribers who have subscribed to the 
enhanced call return service. A "mailbox" for an MS stores 
caller-specific information. The caller-specific information 
may later be retrieved by the MS through interaction with 
the IP 20 as discussed hereinbelow. The IP 20 is a network 
entity that provides and interprets information via local 
processing. In other words, the IP 20 itself may be capable 
of receiving and decoding operational commands from other 
network nodes and then executing those commands. In one 
embodiment, the IP 20 is part of the HLR 23. Alternatively, 
the IP 20 may be an independent physical entity in the 
wireless network. The IP 20 may be able to perform multiple 
activities, e.g., activities similar to those performed by the 
SCP 22. Further, the IP 20 may be SMS (short message 
service) capable. An SMS is a packet-switched messaging 
service that provides store -and-forward functions for the 
handling of short messages destined to or originated from 
the mobile subscribers. 

A cellular wireless network may interconnect with an SS7 
(Signaling System No. 7) network as a backbone network to 
transport IS-41 signaling messages through the mobile tele- 
communications network. SS7 packets may be used to 
convey signaling information from an originating point to a 



16,691 Bl 

6 

destination point through multiple switching nodes in the 
mobile network, which may encompass more than one 
wireless network operated by one or more service providers. 
SS7-based transactions may query databases and invoke 

5 functions at remote points throughout the mobile wireless 
network to establish and maintain calls and to perform 
reliable call management functions. An SS7 backbone net- 
work may be owned and operated by the same service 
provider as the one operating the interconnected wireless 

1Q network. Alternatively, a wireless service provider may join 
an independent SS7 network provider to accomplish desired 
call routing. Service control points (SCPs) 22 are special 
types of end signaling points in an SS7 network that perform 
transaction processing of remote operations. The SCP 22 

15 may support a database to perform the required operations, 
e.g., processing of calling card information. As noted 
hereinbefore, the HLR 23 may perform as an SCP in a given 
wireless network configuration. 
The location registers, e.g., the HLR 23 and the VLR 24, 

2Q are data-based systems that assist in controlling mobile 
subscriber services and contain the records and stored infor- 
mation related to mobile subscribers of a particular mobile 
service provider. The location registers are queried by other 
network entities to obtain the current status, location, and 

^ other information to support calls to and from mobile users 
within the wireless network. Location registers may also 
contain network address translation information to assist in 
the routing of calls to the appropriate network destination. 
The HLR 23 is typically a primary database repository of 

30 subscriber information used to provide control and intelli- 
gence in wireless networks. The HLR 23 thus contains a 
record of subscriber information such as features selected by 
the subscriber as part of the mobile service plan (e.g., call 
forwarding, calling name service, etc.), status of the sub- 

35 scriber (e.g., active, inactive, suspended service, etc.), the 
subscriber's mobile directory number (i.e., the number a 
calling party has to call to reach the mobile subscriber), 
information about the current geographic location of the 
mobile subscriber, etc. The HLR 23 may be shared by more 

40 than one MSC 12,14. The HLR 23 is generally managed by 
the wireless service provider company and represents the 
"home" database of subscribers who have subscribed for the 
wireless service in that home area served by the wireless 
service provider. 

45 The VLR 24 is a database that primarily maintains tem- 
porary records associated with individual network subscrib- 
ers. Thus, the VLR 24 represents a "visitor's" database for 
mobile subscribers who are being served in a defined local 
area. The VLR 24 is also managed by a wireless service 

so provider. However, the VLR 24 and the HLR 23 may be 
managed by the same or by different wireless service pro- 
viders depending on the current geographic location of the 
mobile subscriber in the wireless network. The term "visi- 
tor" may refer to a mobile subscriber who is being served by 

55 one or many systems in the home service area, or an MS who 
is roaming in a non-home, or "visited", service area (i.e., 
service area of a service provider that is different from the 
service provider the MS has signed up with). The VLR 24 
generally contains subscriber location, status, and service 

60 features information that is derived from the relevant HLR, 
here, the HLR 23. The serving MSC 14 may access its 
associated VLR 24 to retrieve information therefrom for the 
handling of calls to and from visiting subscribers. Similar to 
the HLR 23, the VLR 24 may also serve one or more MSCs 

65 as illustrated in FIG. 1. 

The LIDB database 26 is typically maintained by each 
telecommunications service provider as part of its subscriber 
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account management. The LiDB database 26 may store Number (ESN) field, among others, are mandatory; 

caller-specific information (also interchangeably referred to however, the Transaction Capability (TRANSCAP) and the 

herein as the 'calling name information'), e.g., the name of WIN Capability (WINCAP) fields, among others, are 

the caller, the telephone number of the caller, etc. A call sent optional. The total length (in octets) of the * length' field 

to an MS invariably involves the PSTN 18 as part of the call 5 (and, thus, of the REGNOT Invoke message 32 itself) may 

connection process. The calling party information may be vary depending on the content of the optional fields included 

placed in the LEDB database 26 when a call is placed from within the REGNOT Invoke message 32. 

the external network (e.g., the PSTN 18) to the wireless The REGNOT operation may invoke many functions, 

network. The external network, typically the PSTN 18, may e.g., location update, service qualification, authentication 

store the calling name information in the LIDB database 26 reporting, SMS functions, etc. In the messaging shown in 

for a number of reasons, e.g., to validate identity of the caller FIG. 2, the REGNOT Invoke message 32 from the serving 

in the case of collect calls or third party calls. MSC 14 to its associated VLR 24 has the TRANSCAP 

The implementation of an enhanced call return (ECR) (transaction capability) parameter set to indicate that the 

feature in a wireless telephone network is facilitated by the serving MSC 14 may process the TRIGADDRLIST (trigger 

use of a set of messages provided by one of the WIN 15 address fist) parameter in the Registration Notification 

(wireless intelligent network) standards, e.g., the IS-41 Return Result (regnot Return Result) message (shown in 

standard. The ECR feature allows the mobile subscriber to FIG. 4) from the HLR 23. The WINCAP (wireless intelligent 

access caller-specific information for more than one prede- network capability) parameter in the REGNOT Invoke mes- 

termined past caller. Thus, in the event that the MS is unable sage indicates which triggers the serving MSC 14 may 

to answer a call or the caller hangs up prior to the MS ^ support in the TRIGADDRLIST parameter. The HLR 23 

answering the call, the mobile subscriber may activate the may not include those triggers in the TRIGADDRLIST 

ECR service by dialing an access code, e.g., *69. The parameter which may not be supported by the serving MSC 

caller-specific information stored in the IP 20 in the mailbox 14. 

created for the MS may then be accessed by the MS as A "trigger" may include an event or an occurrence of a 

discussed in detail hereinafter. ^ condition that is used to initiate a call processing function. 

By way of explanation, in FIGS. 2, 5 and 15, a "Request" A "trigger" may be useful during a digit analysis process, 

is sent from a first network entity to invoke an application For example, a trigger (in the TRIGADDRLIST from the 

process in a remote network entity, whereas a "Result" is HLR 23) may inform the serving MSC 14 that the MS has 

returned by the remote network entity to send the results of subscribed to a service that allows for call origination to a 

the application process execution to the first network entity 30 number beginning with the digit (e.g., *69 dialing for the 

as indicated by the paired Request-Result messaging illus- ECR service). Therefore, when the serving MSC 14 detects 

trated in FIGS. 2, 5 and 15. The sequence of "Request" and such a trigger condition (i.e., number preceded by a "*"), it 

"Result" messages may be needed to complete an associated sends an Origination Request Invoke message (ORREQ 

IS-41 "operation." It is conventional to represent the Invoke Invoke message shown in FIG. 16) to the MS's HLR 23 as 

component acronym of an operation (e.g., the Location 35 described hereinafter with reference to FIG. 15. The 

Request operation) in all-capital letters (e.g., LOCREQ) and ORREQ Invoke message allows the HLR 23 to evaluate the 

the Return-Result component acronym in all-lowercase let- dialed digits and to provide routing instructions to the 

ters (e.g., locreq) as is shown in FIGS. 2, 5 and 15 for serving system via the Origination Request Return Result 

relevant messages. (orreq) message as shown in FIG. 15. 

Referring now to FIG. 2, a prior art IS-41 messaging for 40 At step (b) in FIG. 2, the VLR 24 associated with the 

an MS registration process 30 in a wireless network (not serving MSC 14 forwards the REGNOT Invoke message to 

shown) is depicted. The MS registration process 30 is the MS's HLR 23. The HLR 23, in turn, returns to the 

initiated when an MS (not shown) first registers with the requesting VLR 24 the profile information for the MS 

wireless network. At step (a), the serving MSC (e.g., the through the Registration Notification Return Result message 

MSC 14) transmits a REGNOT (registration notification) 45 (regnot Return Result) at step (c). An exemplary message 

Invoke message to its associated VLR (e.g., the VLR 24) format for a regnot Return Result message 34 is illustrated 

requesting subscriber profile information for the newly- in FIG. 4. The TRIGADDRLIST (trigger address list) 

registered (or "visiting"*) MS. An exemplary message format parameter has been added to the regnot Return Result 

for a REGNOT Invoke message 32 is illustrated in FIG. 3. message 34 under WIN standard IS (Interim Standard)-771, 

Additional information about the REGNOT Invoke message 50 which, at the time of this writing, is yet to be incorporated 

may be obtained by consulting chapter 5 of the HA/EIA-41, into the TTA/EIA-41 standard. Therefore, additional infor- 

revision D. The registration notification operation is used to matron about the regnot Return Result message may be 

report (to the HLR 23 for the MS) the location of the MS obtained by consulting chapter 5 of the TTA/EIA-41, revi- 

(including the VLR and the MSC currently serving the MS) sion D, and the pertinent documents in the IS-771 standard, 

and, optionally, (1) to validate the MS identity, or (2) to 55 The profile information in the regnot Return Result mes- 

validate the MS and obtain its profile information (from the sage 34 may include validation and service information 

HLR storing the information about the MS). The HLR for stored in the HLR 23 for the MS, e.g., the verification of the 

the MS (e.g., the HLR 23) may normally require location identity of the MS and the services the MS is authorized to 

update notification (through, e.g., the REGNOT Invoke use. The serving MSC 14 may use this information to tailor 

message 32) when the MS changes service areas. 60 the telecommunications services it provides to the visiting 

It is noted that one or more fields within an IS-41 message MS. Finally, at step (d), the VLR 24 forwards the received 

(e.g., the REGNOT Invoke message 32 in FIG. 3) may be regnot Return Result message 34 to the serving MSC 14 as 

'optional' (as indicated by letter "O") and some other fields shown in FIG. 2. This completes the initial registration 

within that message may be 'mandatory* or 'required' (as process for the visiting MS when that MS (not shown) is first 

indicated by letter "M") to form a valid IS-41 message. For 65 detected in the serving MSC's 14 service area. In other 

example, in the REGNOT Invoke message 32, the Mobile words, the serving MSC 14 may now "identify*' the MS and 

Identification Number (MIN) field and the Electronic Serial may, therefore, complete calls originated to and from the MS 
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according to the service profile information received from between a wireless network and a wire line network. The 

the MS's HLR 23. TO-1188 messages are SS7 TCAP (Transaction Capabilities 

The messaging scheme discussed hereinbelow with ref- Application Part) messages that are used by wireline net- 

erence to FIG. 5 illustrates an example of how some of the works to support calling name capability. Therefore, with 

HA/EIA-41 (prior art) messages may be used in a novel way s foe TR-1188 messages, the HLR 23 may retrieve one or 

to enable call return functionality (i.e., the ECR feature) in more parts of the caller-specific information stored in the 

a mobile wireless network. The SERVREQ Invoke message UDB 26 by the PSTN 18. The HLR 23 may perform 

may be used to load a mobile subscriber's mailbox in an IP signaling functions similar to those performed by an SCP 

20 within the wireless network with caller-specific inform a- (e.g., the SCP 22) while launching the TR-1188 Invoke 

tion for a predetermined number of callers who placed calls 10 query 38 to the UDB database 26. Upon receiving the 

in the past to the MS. The caller-specific information stored TR-1188 Invoke message 38, the LIDB database 26 

in the LIDB 26 may thus be loaded into an MS-specific determines, at step (d), if any calling name restrictions have 

mailbox within the IP 20. The SERVREQ Invoke message been imposed by the calling party. In the absence of any 

may also be used in a similar manner to store other kind of calling name restriction, the LIDB 26 returns the calling 

information (from the UDB 26), e.g., specific subscriber- 35 name of the caller via the TR-1188 Return Result message 

related voice or numerical messages, in the MS's mailbox. 39 (i.e., through the generic name parameters in the 

Turning now to FIG. 5, an exemplary sequence 36 of message) to the HLR 23, FIGS. 7 and 8 respectively 

IS-41 messages that may be used to store callernspecific illustrate exemplary message formats for the SS7 TR-1188 

information in a mailbox created in the intelligent peripheral Invoke message 38 and the TR-1188 Return Result message 

(IP) 20 for the called party (i.e., the mobile subscriber) is 20 

illustrated. At step (a), a call originated from an external At step (e) in FIG. 5, the HLR 23 sends a SERVREQ 

telephone network (e.g., the PSTN 18 or another wireless (service request) Invoke message containing the calling 

network) is received by the anchor MSC (e.g., the MSC 12 party name (if available), calling party telephone number 

in FIG. 1). Such a call may be referred to as a 'mobile- (represented by the CNI (calling number information) field, 

terminated call.' Mobile-terminated calls are established ^ which is also referred to as Calling Party Number Digits 

from a telecommunications terminal (i.e., the 'calling party* field) and the called party MDN to the IP 20. An exemplary 

or the 'caller'), which can be either within or outside of the message format for a SERVREQ Invoke message 41 is 

mobile telecommunications network, to an MS (i.e., the illustrated in FIG. 9. Additional information about the 

'called party' or the 'callee')- At step (b), the anchor MSC SERVREQ Invoke message may be obtained by consulting 

12 launches a Location Request Invoke (LOCREQ Invoke) 30 chapter 5 of the TTA/EIA-41, revision D. A SERVREQ 

message to the MS's HLR 23 upon receiving the indication Invoke message 41 is used by a network entity to invoke 

of call initiation (i.e., upon receiving the call placed by a specific service logic execution on another network entity 

caller with the MS as a callee thereof). An exemplary containing service logic for the requested service(s). Here, 

message format for a LOCREQ Invoke message 37 is the HLR 23 uses the SERVREQ Invoke message 41 to load 

illustrated in FIG. 6. Additional information about the 35 the MS mailbox (created in the IP 20 when the MS sub- 

LOCREQ Invoke message may be obtained by consulting scribes to the ECR feature) in the IP 20 with pertinent 

chapter 5 of the 1TA/EIA-41, revision D. The anchor MSC caller-specific information. The number of callers whose 

12 transmits the LOCREQ Invoke message to "inform" the calling name information may be stored in the IP 20 via 

HLR 23 of the receipt of a mobile-terminated call and, thus, individual SERVREQ Invoke messages 41 (generated per 

to obtain call-treatment instructions from the HLR 23, e.g., 40 inbound call) may be predetermined by the mobile service 

how to route the call. provider. Therefore, the IP 20 may discard one or more 

The caller typically dials the MS's mobile directory caller-specific information to maintain the total number of 

number (MDN) to place a call to that MS. This MDN callers whose information are stored in the MS's mailbox 

indicates to the anchor MSC 12 that a mobile-terminated call within the predetermined number specified by the service 

has been received and the same needs to be processed to 45 provider. 

connect the caller to the MS (i.e., the callee). The LOCREQ The intelligent peripheral 20, preferably a voice response 

Invoke message 37 from the anchor MSC 12 to the associ- unit (VRU) (not shown) within the IP 20, timestamps the 

ated HLR 23 may include the digits dialed by the caller to contents of the SERVREQ Invoke message 41 and stores 

place a call to the MS (typically, the MDN for the MS) in the them in the MS's mailbox (as identified by the MDN 

Digits (Dialed) field and may additionally include the digits 50 supplied through the SERVREQ Invoke message 41). In 

in the telephone number of the calling party in the Calling other words, the IP 20 has a record of the date and time of 

Party Number (CPN) Digits field. The calling party number the received call along with the calling name information 

may be part of the calling name information transmitted by (i.e., the name and the telephone number of the caller), 

the call-originating network (e.g., the PSTN 18). Upon which may later be accessed by the MS (as described 

receipt of the LOCREQ Invoke message 37, the HLR 23 55 hereinbelow) as part of the ECR service. The IP 20 acknowl- 

determines whether the called party (i.e., the mobile edges the successful completion of the service requested by 

subscriber) has subscribed to the ECR service and also the transmitting a Service Request Return Result (servreq 

status of the ECR service i.e., whether the service is active Return Result) message to the HLR 23 at step (f). An 

or inactive (due to, e.g., non-payment). exemplary message format for a servreq Return Result 

If the HLR 23 determines that the MS is authorized to use 60 message 42 is illustrated in FIG. 10. Additional information 

the ECR feature, then, at step (c), the HLR 23 transmits a about the servreq Return Result message 42 may be obtained 

Caller Name query to the UDB 26 via a TR-1188 Invoke by consulting chapter 5 of the TIA/EIA-41, revision D. 

message 38 (FIG. 7) that contains the calling party number In an alternative embodiment, the SERVREQ Invoke 

(CPN) or calling directory number field to identify the message 41 may be modified to include the Generalized 

associated caller in the LIDB 26. The TR-1188 messages 65 Tune parameter 43 (FIG. 11) to specify time-of-day, day- 

(including the TR-1188 Invoke message 38 and the TR-1188 of-month, month and year information. Here, the HLR 23 

Return Result message 39 (FIG. 8)) provide an interface may provide the time information through the SERVREQ 
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Invoke message 41 thus modified. The IP 20 may not need EIA-41, revision D. Hie transmission of the locreq Return 

to perform the timestamping operation as described herein- Result message 46 completes the location request operation 

before in the preceding paragraph. An exemplary message initiated by the LOCREQ Invoke message 37 transmitted 

format for the Generalized Time parameter 43 is illustrated earlier by the anchor MSC 12 at step (b). If the serving MSC 

in FIG. 11. Additional information about the Generalized 5 14 and the anchor MSC 12 are the same, then the route 

Time parameter 43 may be obtained by consulting chapter 5 request operation may not be needed. However, when addi- 

of the TIA/EIA-41, revision D. tional call routing is required, then the 'termination list* 

After loading the caller-specific information into the MS's parameter in the locreq Return Result message 46 may 

mailbox in the IP 20, the HLR 23, in response to the contain the TLDN received from the new serving MSC 14. 

earlier-sent LOCREQ Invoke message 37, transmits at step 10 The anchor MSC 12 then routes the inbound call to the 

(g) a ROUTEREQ (Routing Request) Invoke message to the serving MSC 14 using the TLDN at step (1). The serving 

VLR 24 associated with the serving MSC 14. An exemplary MSC 14 associates the incoming call to the TLDN with the 

message format for a ROUTEREQ Invoke message 44 is previous ROUTEREQ Invoke message 44 identifying the 

illustrated in FIG. 12. Additional information about the MS (not shown) as the recipient of the incoming call. 

ROUTEREQ Invoke message 44 may be obtained by con- 15 Therefore, at step (m), the serving MSC 14 "pages" the 

suiting chapter 5 of the TIA/EIA-41, revision D. handset (or any other suitable communication device used 

The HLR 23 obtains the information regarding the des- by the mobile subscriber) to alert the mobile subscriber of 

tination VLR (e.g., the VLR 24) and the serving MSC 14 the incoming call. A call is established between the MS and 

(that is currently serving the MS) through the REGNOT the caller when the MS answers in response to the "paging" 

operation as discussed hereinbefore with reference to FIG. 2. 20 bv me servin S MSC 14 - 

The HLR 23 initiates the ROUTEREQ operation to query Once the call is established between the MS and the 

the serving system as to the preferred method of routing the calling party (as described hereinbefore with reference to the 

pending call to the MS identified via the digits dialed by the messaging scheme illustrated in FIG. 5), the MS may 

caller (e.g., the MDN) as supplied in the LOCREQ Invoke continue the conversation with the caller. However, in the 

message 37. The VLR 24 forwards the ROUTEREQ Invoke 25 event that the mobile subscriber is unable to answer the call 

message 44 received from the HLR 23 to the serving MSC or the caller hangs up prior to the mobile subscriber answer- 

14 at step (h). The serving MSC 14 allocates a TLDN ing the call, the mobile subscriber may activate the enhanced 

(temporary local directory number) for the call and transmits call return service by dialing an access code, e.g., *69, as 

that TLDN (as part of the requested routing information) to discussed hereinbelow with reference to FIG. 15. Upon 

the VLR 24 through a Digits (Destination) field in the 30 activation of the ECR service, the mobile subscriber may be 

Routing Request Return Result (routereq Return Result) allowed to interact with the IP 20 (preferably through the 

message at step (i). An exemplary message format for a VRU in the IP 20) to obtain caller-specific information for 

routereq Return Result message 45 is illustrated in FIG. 13. a predetermined number of past callers from the MS's 

Additional information about the routereq Return Result mailbox in the IP 20. 

message 45 may be obtained by consulting chapter 5 of the 35 Referring now to FIG. 15, an exemplary messaging 

TIA/EIA-41, revision D. The VLR 24 forwards the TLDN- scheme 50 whereby a modified SRFDIR Invoke message 60 

containing routereq Return Result message 45 to the HLR (FIG. 21) may be utilized to allow a mobile subscriber to 

23 at step (j). However, in an alternative embodiment, the interact with the IP 20 to retrieve the call return information 

HLR 23 may transmit the ROUTEREQ Invoke message 44 from the subscriber's mailbox in the IP 20 is illustrated. The 

directly to the serving MSC 14, which, in turn, may directly 40 serving MSC 14 receives the access code (e.g., "*69") dialed 

send the routereq Return Result message 45 to the HLR 23. by the MS to access the ECR service at step (a) in FIG. 15. 

In mobile telecommunications, a TLDN may be required As noted hereinbefore, when the serving MSC 14 detects a 

to deliver a call to a roaming subscriber (i.e., the MS). A trigger condition (e.g., a number preceded by a "*"), it sends 

TLDN is a real NANP (North American Numbering Plan) an Origination Request Invoke message (ORREQ Invoke) to 

directory number that is assigned by the serving system to 45 the MS's HLR 23. An exemplary message format for an 

roaming subscribers for a brief period (e.g., about 20 ORREQ Invoke message 51 is illustrated in FIG. 16. Addi- 

seconds) to support call delivery. The NANP allocates tional information about the ORREQ Invoke message 51 

unique 10-digit directory numbers (e.g., regular 10-digit may be obtained by consulting chapter 5 of the TIA/EIA-41, 

phone numbers) to telephone service subscribers. The serv- revision D. The HLR 23 may include the SCP22 and, hence, 

ing MSC 14 assigns and maps the TLDN to the MS's 50 the HLR 23 may perform SCP-type functions such as, e.g., 

identity at the serving system. The incoming call is redi- receiving the ORREQ Invoke message 51 from the serving 

rected (by the anchor or originating MSC 12 as discussed MSC 14 at step (b). The ORREQ Invoke message 51 allows 

hereinbelow) to the serving MSC 14, via the PSTN 18, using the HLR 23 (i.e., the SCP 22 within the HLR 23) to evaluate 

the TLDN as the called party's "actual" phone number. The the dialed digits (here, digit "6" followed by digit "9") and 

call may then be established to the MS at the serving system. 55 to provide routing instructions to the serving system via the 

A set of NANP directory numbers are reserved by service Origination Request Return Result (orreq) message at step 

providers as TLDNs and the TLDNs are not permanently (1) as described hereinbelow. In an alternative embodiment, 

assigned to mobile subscribers in the system. TLDNs are the serving MSC 14 may send the ORREQ Invoke message 

dynamically allocated and released when call delivery is 51 directly to an independent SCP that may not be part of an 

completed. 60 HLR. 

Upon receiving the routereq Return Result message 45 An origination request operation (implemented by the 

with TLDN, the HLR 23 transmits a locreq (location ORREQ Invoke message and the orreq messages) is used to 

request) Return Result message to the originating MSC 12 request call origination treatment on behalf of a registered 

at step (k). An exemplary message format for a locreq MS. The MS registration process has been described here- 

Retura Result message 46 is illustrated in FIG. 14. Addi- 65 inbefore with reference to FIG. 2. An MSC (i.e., the serving 

tional information about the locreq Return Result message MSC 14) sends an ORREQ Invoke message 51 to an SCP 

46 may be obtained by consulting chapter 5 of the TIA/ (i.e., the SCP 22 within the HLR 23) notifying the service 
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logic (not shown) within the SCP 22 that an MS origination 
trigger criterion has been satisfied. The ORREQ Invoke 
message 51 may include as much information as is known 
at the current state of the call so that the service logic within 
the SCP 22 may use that information. In the messaging 
scheme illustrated in FIG. 15, the ORREQ Invoke message 
51 may include the dialed digits (i.e., the number "69") and 
the MDN (mobile directory number) for the MS registered 
with the serving MSC 14. 

Prior to generating the Origination Request Return Result 
(orreq) message, the SCP 22 (or the HLR 23 functioning as 
the SCP 22) may transmit a Seize Resource Invoke message 
to the IP 20 at step (c) (FIG. 15) to request reservation of a 
specific resource (e.g., the MS's mailbox) or a set of 
specialized resources within the IP 20. This action prepares 
the IP 20 for interactions with a device, e.g., the handset (not 
shown) of the mobile subscriber. An exemplary message 
format for a Seize Resource Invoke message 52 is illustrated 
in FIG. 17. Additional information about the Seize Resource 
Invoke message 52 may be obtained by consulting chapter 
5 of the HA/EIA-41, revision D. The specialized resource 
(i.e., standard specialized resource) parameter and the pri- 
vate specialized resource parameter (in the Seize Resource 
Invoke message 52) together define the SRFCapability 
(Specialized Resource Function Capability) parameter. The 
SRFCapability parameter identifies the specialized resource 
capabilities (within the IP 20) requested by the SCP 22. The 
invocation of the interactive implementation of the ECR 
functionality through the IP 20 may be indicated by inclu- 
sion of the standard specialized resource parameter within 
the Seize Resource Invoke message. The caller-specific 
information stored in the mailbox of the mobile subscriber 
may be considered part of the private specialized resource 
stored within the IP 20. 

The IP 20 shows its willingness to provide access to the 
requested specialized resource by transmitting a TLDN in 
the Seize Resource Return Result message to the SCP 22 at 
step (d). An exemplary message format for a Seize Resource 
Return Result message 53 is illustrated in FIG. 18. Addi- 
tional information about the Seize Resource Return Result 
message 53 may be obtained by consulting chapter 5 of the 
TIA/EIA-41, revision D. The TLDN transmitted by the IP 20 
through the Seize Resource Return Result message 53 may 
be the same or may be different from the TLDN described 
hereinbefore with reference to the routereq Return Result 
message 45 in FIG. 5. The TLDN received from the IP 20 
may be used by the serving MSC 14 to set up a call to the 
IP 20 as described hereinbelow. 

The SCP 22 (within the HLR 23) forwards the TLDN 
received from the IP 20 at step (d) to the serving MSC 14 in 
a CONNRES (connect resource) Invoke message at step (e). 
An exemplary message format for a CONNRES Invoke 
message 54 is illustrated in FIG. 19. Additional information 
about the CONNRES Invoke message 54 may be obtained 
by consulting chapter 5 of the TIA/EIA-41, revision D. A 
Connect Resource operation provides part of the protocol 
needed to support IP interactions in a wireless network. The 
CONNRES Invoke message 54 is sent from an SCP (i.e., the 
SCP 22 within the HLR 23) to a serving MSC (i.e., MSC 
14), instructing the serving MSC 14 to connect the indicated 
call to the specified IP 20 for access to a special resource 
within the IP 20. When an SCP resides within an HLR, the 
SCP may initially send the CONNRES Invoke message 54 
to the HLR, which, in turn, may transfer the message to the 
appropriate MSC. A CONNRES Invoke message 54 may not 
have a Return Result message associated with it. However, 
upon transmitting the CONNRES Invoke message 54 to the 
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serving MSC 14, the SCP 22 may wait for an acknowledge- 
ment from the IP 20 (e.g., the INSTREQ Invoke message as 
described hereinbelow) giving the SCP 22 an indication of 
the call connection to the IP 20. Sample operation scenarios 

5 for the Connect Resource operation are illustrated in 
chapter-3 of the TIA/EIA-41, revision D. 

Hie serving MSC 14 sets up a call, at step (f) in FIG. 15, 
to the IP 20 using the TLDN received in the CONNRES 
Invoke message 54. Upon connection, the IP 20 transmits, at 

10 ste P (&)> m INSTREQ (instruction request) Invoke message 
to the SCP 22 requesting instructions from the SCP 22 
regarding the service being invoked. An exemplary message 
format for an INSTREQ Invoke message 55 is illustrated in 
FIG. 20. Additional information about the INSTREQ Invoke 
message 55 may be obtained by consulting chapter 5 of the 

15 TIA/EIA-41 , revision D . An Instruction Request operation is 
used when an SRF (Special Resource Function) within the 
IP 20 determines that one of the SRF's resources, allocated 
by the Seize Resource operation, has been seized. The SRF 
(not shown) within the IP 20 may wait for an SRFDIR 

20 Invoke message (defined hereinbelow with reference to FIG. 
21) or an Instruction Request Return Result message (shown 
in FIG. 24) from the SCP 22 as an acknowledgment of its 
earlier INSTREQ Invoke message 55 as well as a source of 
further call processing instructions. 

25 In the messaging scheme shown in FIG. 5, the SCP 22 
sends an SRFDIR (specialized resource function directive) 
Invoke message to the IP 20 at step (h) in response to the 
earlier INSTREQ Invoke message 55 from the IP 20. An 
exemplary message format for an SRFDIR Invoke message 

3 0 60 is illustrated in FIG. 21 and discussed hereinbelow with 
reference thereto. The SRFDirective operation may be used 
by the service control logic within the SCP 22 to direct the 
operation of the IP 20 that provides user interaction. The 
SRFDIR Invoke message 60 may contain an EXESCR 

35 (execute script) parameter (as part of controlling specialized 
resources within the IP 20) specifying which audio or video 
script (already stored in the IP 20) is to be executed by the 
IP 20. The SRFDIR Invoke message 60 thus instructs the IP 
20 to access the specialized resource (i.e., the mailbox for 

40 the MS) stored therein via interaction with the MS (not 
shown) upon execution of a specified script. Some examples 
of the SRFDirective operation may be found in chapter-3 of 
the TIA/EIA-41, revisioo D. 

Referring now to FIG. 21, an exemplary message format 

45 for the SRFDIR Invoke message 60 to facilitate interaction 
between the IP 20 and an MS is illustrated. The SRFDIR 
Invoke message 60 shown in FIG. 21 is a modified from the 
prior art SRFDIR Invoke message (not shown) to include an 
"access key*' field (e.g., the Mobile Directory Number field) 

50 that identifies the MS the IP 20 is to interact with. The 
"access key" allows direct addressing of the IP 20 so as to 
enable the IP 20 to access a specific mailbox for a specific 
MS and, then, to interact with the MS. In other words, the 
modified SRFDIR Invoke message 60 allows the IP 20 to 

55 identify the MS (and its mailbox) as well as to initiate 
interaction with that MS. The SRFDIR Invoke message 60 
may be used by the SCP 22 to command the IP 20, e.g., to 
play an announcement to the MS or to collect digits (entered 
by the MS through the mobile handset keypad) that may 

60 later be returned to the SCP 22 as discussed hereinbelow. 
The SRFDIR Invoke message 60 may further include an 
'Execute Script' (EXESCR) field, which provides the IP 20 
with information (e.g., memory location address) necessary 
to access one or more audio or video scripts stored within the 

65 IP 20 and then to execute those scripts. 

Returning oow to FIG. 15, after receiving the SRFDIR 
Invoke message 60, the IP 20 executes, at step (i), the audio 
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or video script stored therein at a location referred to in the 
EXESCR field within the SRFDIR Invoke message 60. The 
script being executed by the IP 20 may include audio 
instructions inviting the MS to interact with the IP 20 and to 
input one or more choices (through appropriate digits on the 
mobile handset) suggested in the audio instructions being 
played by the IP 20. Alternatively, in the absence of voice- 
based interaction, the IP 20 may provide a displayed set of 
options oa the mobile handset if the mobile handset has a 
built-in display. The instructions (stored in the IP 20) 
referred to by the EXESCR field within the SRFDIR Invoke 
message 60 may include an executable computer program, 
which, upon execution, may prepare the IP 20 to perform a 
specialized resource function (e.g., to play an 
announcement, to collect digits dialed by the MS and/or to 
recognize voice input from the MS). For execution of an 
audio script, the IP 20 may include an interactive voice 
response unit (IVR) (not shown) that may "read" (e.g., in a 
synthesized speech) the calling party's name, the calling 
party's telephone number and the time the calling party's 
call was received in the MS's mailbox to the MS and may 
"listen" for spoken commands from the MS or may accept 
direct input (in the form of digits dialed on the mobile 
handset) from the MS (in response to the options "read" by 
the IVR) to initiate the desired action. 

A sample script that may be "announced" by the IVR unit 
(not shown) in the IP 20 using pre-recorded digitized human 
voice samples is given below. It is noted that the IVR unit 
may include an audio speech processing unit, e.g., a DIA- 
LOGIC® speech processing card manufactured by Dialogic 
Corporation, 1515 Route 10, Parsippany, N.J., USA 07054, 
to generate human voice announcements upon execution of 
the specified script. The following sample script "announce- 
ment" also includes options given to the MS by the IP 20 to 
input a choice by pressing (or dialing) a digit on the mobile 
handset. Alternatively, the MS may be prompted to speak a 
choice, and a speech recognition unit (not shown) in the IVR 
unit may detect what option the MS has selected during the 
script announcement. In the sample announcement script 
below, the words NAME, NUMBER and TIME are vari- 
ables that may be filled-in by the IVR (while converting that 
information into audible speech) based on the data stored in 
the MS's mailbox in the IP 20. The "speech" part of the 
executed script is shown in italics, whereas the data input 
part (i.e. 7 the interaction between the MS and the IP 20) is 
printed as normal text within the announcement script given 
below. 

Sample Announcement Script 
First Announcement 
Please: 

Press 1 to send current selection [to be dialed by the 

serving MSC 14] 
Press 2 to scroll down 
Press 3 to scroll up 
Press 9 to end this call 
Second Announcement 

Caller: (NAME, NUMBER, who called at TIME) 

IVR waits for an input from the MS 

if input=l, then IVR places selected caller's number into 
the 'digits' parameter of the srfdir Return Result mes- 
sage to be sent to the SCP 22 

if input=2, then IVR "scrolls down" to the next selection 
stored in the MS's mailbox 

if input=3, then IVR "scrolls up" to the previous selection 
stored in the MS's mailbox 

if input-9, then IP sends termination designation to the 
SCP in srfdir Return Result (if no input is detected, then 
IVR proceeds to the next selection) 
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Third Announcement (when input=2 or when no input is 
detected) 

Caller: (NAME, NUMBER, who called at TIME) 
IVR again waits for an input from the MS 

s ... this process is repealed until all the callers stored in 
the MS's mailbox are covered. 
It is noted that the caller information may be announced 
in a number of different ways, e.g., starting with the most 
recent caller first or starting with a caller whose first name 

30 appears first when all the caller names (stored in the mailbox 
for the MS) are arranged in alphabetical order. The response 
from the MS indicating which of the past callers to call may 
be in the form of DTMF (dual-tone multi-frequency) input 
digit(s) (dialed through the MS's handset) and may be 
interactively received by the IP 20 at step (j). The scrolling 

15 functionality may allow the MS to go backward or forward 
and thereby "scan" the caller-specific information for each 
of a number of past callers stored in the MS's mailbox. The 
ECR feature thus allows an MS to access caller-specific 
information (including the time of call reception) for not just 

20 the last (in time) caller, but for a predetermined number of 
past callers. 

The MS may hang up after listening to the announcement 
from the IP 20. However, if the MS chooses a particular 
caller to place a call to (via voice input or via digit input 

25 selection during the announcement script execution), the IP 
20 may convey the telephone number of the selected caller 
to the SCP 22 using the Digits parameter in a SRFDirective 
(srfdir) Return Result message at step (k). An exemplary 
message format for an srfdir Return Result message 62 is 

30 illustrated in FIG. 22. Additional information about the 
srfdir Return Result message 62 may be obtained by con- 
sulting chapter 5 of the T1A/EIA-41, revision D. A voice 
input from the MS may thus be converted into correspond- 
ing digit selection by the speech recognition unit (not 

35 shown) in the IP 20 prior to sending the corresponding 
calling party number (CPN) through the Digits parameter in 
the srfdir Return Result message. It is noted that sample 
messaging schemes for voice recognition features for one or 
more network entities (thereby allowing a mobile subscriber 

40 to interact with those network entities via voice inputs 
instead of keypad inputs) are illustrated in chapter-3 of the 
HA/E1A-41, revision D. 

The Digits parameter in the srfdir Return Result message 
62 may contain "zero (0)" indicating either that the MS did 

45 not enter any digits before time-out or that all announce- 
ments were played to the MS without any subsequent input 
from the MS. The SCRRESULT (script result) parameter in 
the srfdir Return Result message 62 may indicate the result 
of the script required to be executed by the EXESCR 

50 parameter in the corresponding SRFDIR Invoke message 
60. When the MS decides to place a call to one of the past 
callers from the MS's mailbox in the IP 20, the MS may 
indicate that selection in one of many ways, e.g., pressing 
the digit "1" on the mobile handset keypad as indicated 

55 hereinbefore in the sample announcement script. The selec- 
tion entered by the MS (which is represented as the calling 
party telephone number in the Digits field of the srfdir 
Return Result message 62) is then returned to the serving 
MSC 14 via the orreq message (Origination Request Return 

60 Result message) from the SCP 22 to the serving MSC 14 at 
step (1) in FIG. 15. An exemplary message format for an 
orreq message 64 is illustrated in FIG. 23. Additional 
information about the orreq message 64 may be obtained by 
consulting chapter 5 of the TIA/EIA-41, revision D. The 

65 number of the party the MS wishes to establish a call to is 
conveyed to the serving MSC 14 via the TERMUST 
(termination list) parameter in the orreq message 64. 
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In response to the orreq message 64 from the SCP 22, the 
serving MSC 14 may send a release message (the Call 
Release message) to the [P 20 at step (m). The release 
message may allow the IP 20 to free up the seized resource 
(i.e., the MS's mailbox) for other applications, if any. 
Thereafter, the serving MSC 14 may initiate a call at step (n) 
to the number contained in the TERMLIST parameter, i.e., 
the telephone number of one of the past callers (CPN) 
selected by the MS to be connected to. Finally, at step (o), 
the SCP 22 sends an instruction request Return Result 
message (the instreq Return Result message) to the IP 20 to 
indicate successful completion of instruction request opera- 
tion initiated by the INSTREQ Invoke message 55 earlier at 
step (g). An exemplary message format for an instreq Return 
Result message 66 is illustrated in FIG. 24. Additional 
information about the instreq Return Result message 66 may 
be obtained by consulting chapter 5 of the T1A/EIA-41, 
revision D. The instreq Return Result message 66 may 
further signify to the IP 20 that operations with the seized 
resource (in the IP 20) have been successfully completed. 

It is noted that various messages described hereinbefore 
with reference to FIGS. 2, 5 and 15 may also be imple- 
mented as defined in the Interim Standard (IS)-771 for 
wireless intelligent networks (WIN), except for the mes- 
sages for the LOCREQ operation (i.e., the LOCREQ Invoke 
message and the locreq Return Result message) which may 
be implemented as defined in the IS-764 standard. Relevant 
portions of the IS-771 standard and the IS-764 standard are 
incorporated herein by reference. 

The foregoing messaging schemes outlined in FIGS. 5 
and 15 illustrate an example of how some of the TIA/EIA-41 
messages may be used in a novel way to enable call return 
functionality (i.e., the ECR feature) in a mobile wireless 
network. The SERVREQ Invoke message may be used to 
load a mobile subscriber's mailbox in an IP within the 
wireless network with caller-specific information for a pre- 
determined number of callers who placed calls in the past to 
the MS. The caller-specific information stored in the LIDB 
(line information database) may thus be loaded into an 
MS-specific mailbox within the IP. The SERVREQ Invoke 
message may also be used in a similar manner to store other 
kind of information (from the LIDB), e.g., specific 
subscriber-related voice or numerical messages, in the MS's 
mailbox. 

A modified SRFDIR Invoke message with an added 
"access key" (e.g., the 'MDN' parameter in the exemplary 
SRFDIR Invoke message 60 shown in FIG. 21) may be used 
by the network service provider to access the mobile sub- 
scriber's mailbox in the IP and also to prepare the IP for 
interactive communication with the mobile subscriber. The 
IP may be configured to "interpret" voice commands/ 
selections from the mobile subscriber in order to implement 
the ECR feature. The IP-based ECR service may allow a 
mobile subscriber to stay informed of any missed calls and 
also to be able to access one or more prior callers without the 
need to personally remember the caller-specific data (e.g., 
caller's name or telephone number). The ECR functionality 
may, however, be implemented with other messages (that 
may be from standards other than the TIA/EIA-41 standard) 
utilized in a manner similar to that described hereinbefore 
with reference to the SERVREQ Invoke and the SRFDIR 
Invoke messages. 

While several preferred embodiments of the invention 
have been described, it should be apparent, however, that 
various modifications, alterations and adaptations to those 
embodiments may occur to persons skilled in the art with the 
attainment of some or all of the advantages of the present 
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invention. It is therefore intended to cover all such 
modifications, alterations and adaptations without departing 
from the scope and spirit of the present invention as defined 
by the appended claims. 
What is claimed is: 

1. A method for enabling enhanced call return in a 
wireless network, the method comprising: 

receiving an incoming telephone call at an anchor mobile 
switching center (MSC) within the wireless network 
from a caller, wherein the incoming telephone call 
identifies a mobile subscriber (MS) as a callee thereof; 
capturing caller-specific information for the caller, 
wherein the caller-specific information includes at least 
one of the name of the caller and the telephone number 
of the caller, and wherein capturing the caller-specific 
information includes storing the caller-specific infor- 
mation into an LIDB (line information database) within 
the wireless network upon origination of the incoming 
telephone call; 
configuring an intelligent peripheral (IP) within the wire- 
less network to maintain a storage for the caller-specific 
information for each of a predetermined number of past 
callers placing calls to the mobile subscriber, and 
storing the caller-specific information into the IP, wherein 
storing the caller-specific information into the IP 
includes: 

informing a home location register (HLR) for the 
mobile subscriber of receipt of the incoming tele- 
phone call; 

the HLR retrieving the caller-specific information from 
the LIDB after being informed of the receipt of the 
incoming telephone call; and 
transferring the caller-specific information to the IP via 
a first message from the HLR to the IP, wherein the 
first message from the HLR to the IP is a service 
request (SERVREQ) invoke message. 

2. The method as recited in claim 1, wherein informing 
the HLR is accomplished by transmitting a location request 
invoke (LOCREQ Invoke) message having the telephone 
number of the caller from the anchor MSC to the HLR. 

3. The method according to claim 1, further comprising 
prior to the HLR retrieving the caller-specific information 
from the LIDB: 

determining a content of the caller-specific information 
the mobile subscriber is authorized to receive. 

4. The method as in claim 1, further comprising: 
the IP storing a date/time information about the incoming 

telephone call along with the caller-specific informa- 
tion. 

5. The method of claim 4, further comprising: 
transmitting a second message from the IP to the HLR 

acknowledging receipt by the IP of the caller-specific 
information sent by the HLR. 

6. The method according to claim 5, wherein the second 
message from the IP to the HLR is a service request Return 
Result message. 

7. The method of claim 1, further comprising: 
allowing the MS to access the caller-specific information 

stored in the IP. 

8. The method according to claim 7, wherein allowing the 
MS to access the caller-specific information includes: 

receiving an indication from the MS requesting access to 
the caller-specific information, wherein the indication 
includes a first access parameter, and wherein the IP is 
configured to identify the caller-specific information 
for the MS using the first access parameter; 
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obtaining a temporary local directory number (TLX)N) 
from the IP, wherein the IP is configured to supply the 
TLDN to indicate readiness of the IP to provide access 
to the caller-specific information stored therein; 

setting up a first call to the IP using the TLDN obtained 
from the IP; 

receiving an instruction request from the IP as to how the 
first call is to be processed by the IP; and 

supplying the first access parameter and a second access 
parameter to the IP using a message in response to the 
instruction request, thereby instructing the IP to access 
the caller-specific information stored therein using the 
first access parameter and to execute an announcement 
script using the second access parameter so as to 
initiate interaction with the MS to allow the MS to 
access the caller-specific information. 

9. The method of claim 8, wherein the first access 
parameter is a mobile directory number (MDN) for the 
mobile subscriber. 

10. The method as recited in claim 8, wherein the second 
access parameter is an execute script (EXESCR) parameter 
identifying the announcement script to be executed by the IP. 

11. The method as in claim 8, wherein the message is a 
special resource function directive (SRFDIR) Invoke mes- 
sage. 

12. The method according to claim 8, wherein obtaining 
the TLDN from the IP comprises: 

transmitting a request to the IP to reserve the caller- 
specific information as a 

specialized resource; and configuring the IP to supply the 
TLDN in response to the request when the IP 

dedicates the specialized resource for access by the MS. 

13. The method as in claim 8, further comprising: 
allowing the MS to place a second call to the caller during 

the interaction with the IP. 

14. The method as recited in claim 13, wherein allowing 
the MS to place the second call includes: 

receiving a selection from the MS during the interaction 
with the IP, wherein the selection identifies the caller as 
a recipient of the second call; and 

placing the second call to the caller based on the selection 
received from the MS. 

15. A method for enabling enhanced call return in a 
wireless network, the method comprising: 

receiving an mcoming telephone call at an anchor mobile 
switching center (MSC) within the wireless network 
from a caller, wherein the incoming telephone call 
identifies a mobile subscriber (MS) as a callee thereof; 50 

capturing caller-specific information and storing the 
caller-specific information into an LIBD (line informa- 
tion database) within the wireless network upon origi- 
nation of the incoming telephone call for the caller, 
wherein the caller-specific information includes at least 55 

. one of the name of the caller and the telephone number 
of the caller; and 

storing the caller-specific information into an intelligent 
peripheral (IP) within the wireless network, wherein 
storing the caller-specific information into the IP 
includes: 

informing a home location register (HLR) for the 
mobile subscriber of receipt of the incoming tele- 
phone call; 

the HLR retrieving the caller-specific information from 
the LIDB after being informed of the receipt of the 
incoming telephone call; and 
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transferring the caller-specific information to the IP via 
a first message from the HLR to the IP, wherein the 
first message from the HLR to the IP is a service 
request (SERVREQ) Invoke message. 

16. A method for enabling enhanced call return in a 
wireless network, the method comprising: 

receiving an incoming telephone call at an anchor mobile 
switching center (MSC) within the wireless network 
from a caller, wherein the incoming telephone call 
identifies a mobile subscriber (MS) as a callee thereof, 

capturing caller-specific information and storing the 
caller-specific information into an LIBD (line informa- 
tion database) within the wireless network upon origi- 
nation of the incoming telephone call for the caller, 
wherein the caller-specific information includes at least 
one of the name of the caller and the telephone number 
of the caller; 

storing the caller-specific information into an intelligent 
peripheral (IP) within the wireless network, wherein 
storing the caller-specific information into the IP 
includes: 

informing a home location register (HLR) for the 
mobile subscriber of receipt of the incoming tele- 
phone call; 

the HLR retrieving the caller-specific information from 
the LIDB after being informed of the receipt of the 
incoming telephone call; and 
transferring the caller-specific information to the IP via 
a first message from the HLR to the IP; 
the IP storing a date/time information about the incoming 
telephone call along with the caller-specific informa- 
tion; and 

transmitting a second message from the IP to the HLR 
acknowledging receipt by the IP of the caller-specific 
information sent by the HLR. 

17. The method according to claim 16, wherein the second 
message from the IP to the HLR is a service request Return 
Result message. 

18. A wireless communication system comprising: 

a line information database (LIDB) configured to store 
caller-specific information therein, wherein the LIDB 
receives the caller-specific information when a caller 
originates a telephone that identifies a mobile sub- 
scriber (MS) as a callee thereof; 

an originating mobile switching center (MSC) configured 
to receive the telephone call and to generate a first 
message in response thereto; 

a home location register (HLR) coupled to the originating 
MSC, wherein the HLR is configured to receive the first 
message and to responsively retrieve one or more parts 
of the caller-specific information from the LIDB; 

an intelligent peripheral (IP) coupled to the HLR, wherein 
the HLR is configured to transfer said one or more parts 
of the caller-specific information to the IP via a second 
message from the HLR to the IP; 

a serving MSC configured to receive an indication from 
the MS requesting an access to said one or more parts 
of the caller-specific information stored in the IP; and 

a service control point (SCP) coupled to the serving MSC, 
wherein the serving MSC is configured to transfer the 
indication from the MS to the SCP via a third message 
from the serving MSC to the SCP. 

19. The system as in claim 18, wherein the first message 
from the originating MSC to the HLR is a location request 
invoke (LOCREQ Invoke) message, and wherein the 
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LOCREQ Invoke message carries a telephone number of the 
caller as an indication of receipt of the telephone call by the 
originating MSC. 

20. The system of claim 18, wherein in response to the 
first message the HLR is configured to determine whether 
the mobile subscriber is authorized to receive said one or 
more parts of the caller-specific information. 

21. The system as recited in claim 18, wherein in response 
to the first message the HLR is configured to transmit a 
query to the UDB to retrieve said one or more parts of the 
caller-specific information, and wherein the LIDB is con- 
figured to transmit said one or more parts of the caller- 
specific information to the HLR using a return result mes- 
sage in response to the query. 

22. The system as in claim 21, wherein prior to sending 
said one or more parts of the caller-specific information to 
the HLR, the UDB is configured to check for a restriction 
on transmission of at least one of said one or more parts of 
the caller-specific information and to block the transmission 
of said at least one of said one or more parts of the 
caller-specific information through the return result message 
when the restriction is present. 

23. The system as recited in claim 18, wherein the second 
message from the HLR to the IP is a service request 
(SERVREQ) Invoke message containing therein said one or 
more parts of the caller-specific information. 

24. The system as in claim 23, wherein the IP is config- 
ured to transmit a service request return result message to the 
HLR acknowledging receipt of the SERVREQ Invoke mes- 
sage. 

25. The system of claim 18, wherein the IP is configured 
to store therein said one or more parts of the caller-specific 
information received via the second message along with a 
date/time stamp therefor. 

26. The system according to claim 18, wherein said one 
or more parts of the caller-specific information comprise at 
least one of a name of the caller; and a telephone number of 
the caller. 

27. The system according to claim 18, wherein the third 
message includes an origination request (ORREQ) Invoke 
message. 

28. The system of claim 18, wherein after receipt of the 
indication the SCP is configured to initiate an operation to 
the IP to retrieve a routing information therefrom and to 
instruct the IP to make said one or more parts of the 
caller-specific information available for the access by the 
MS. 

29. The system as in claim 28, wherein the operation 
includes a seize resource operation. 

30. The system as recited in claim 28, wherein the SCP is 
configured to process the indication to determine whether 
the MS is authorized to have the access to said one or more 
parts of the caller-specific information prior to initiating the 
operation to the IP. 

31. Hie system according to claim 28, wherein the routing 
information includes a TLDN (temporary local directory 
number). 

32. The system of claim 28, wherein the SCP is configured 
to transfer the routing information retrieved from the IP to 
the serving MSC, wherein the serving MSC is configured to 
setup a first call to the IP using the routing information 
received from the SCP, and upon setup of the first call the 
SCP is configured to send a fourth message to the IP, 
wherein the fourth message includes an access key that 
enables the IP to identify said one or more parts of the 
caller-specific information associated with the MS. 

33. The system as recited in claim 32, wherein the fourth 
message includes a specialized resource function directive 
(SRFDIR) Invoke message. 

34. The system as in claim 33, wherein the access key is 
provided within a length field of the SRFDIR Invoke 
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message, and wherein the access key is a mobile directory 
number (MDN) for the MS. 

35. The system of claim 32, wherein the fourth message 
includes a script location information instructing the IP to 

S interact with the MS by executing an announcement script 
stored within the IP, thereby allowing the MS to access said 
one or more parts of the caller-specific information stored in 
the IP. 

36. The system according to claim 35, wherein the IP is 
10 configured to allow the MS to place a second call to the 

caller during execution of the announcement script. 

37. A wireless communication system comprising: 

a line information database (UDB) configured to store 
caller-specific information therein, wherein the UDB 

15 receives the caller-specific information when a caller 
originates a telephone that identifies a mobile sub- 
scriber (MS) as a callee thereof, 
an originating mobile switching center (MSC) configured 
to receive the telephone call and to generate a first 

20 message in response thereto; 

a home location register (HLR) coupled to the originating 
MSC, wherein the HLR is configured to receive the first 
message and to responsively transmit a query to the 

25 UDB to retrieve one or more parts of the caller-specific 
information from the LIDB, and wherein the UDB is 
configured to transmit said one or more parts of the 
caller-specific information to the HLR using a return 
result message in response to the query; and 

30 an intelligent peripheral (IP) coupled to the HLR, wherein 
the HLR is configured to transfer said one or more parts 
of the caller-specific information to the IP via a second 
message from the HLR to the IP. 

38. The system as in claim 37, wherein prior to sending 
35 said one or more parts of the caller-specific information to 

the HLR, the LIDB is configured to check for a restriction 
on transmission of at least one of said one or more parts of 
the caller-specific information and to block the transmission 
of said at least one of said one or more parts of the 
4Q caller-specific information through the return result message 
when the restriction is present. 

39. A wireless communication system comprising: 

a line information database (LIDB) configured to store 
caller-specific information therein, wherein the LIDB 
45 receives the caller-specific information when a caller 
originates a telephone that identifies a mobile sub- 
scriber (MS) as a callee thereof; 
an originating mobile switching center (MSC) configured 
to receive the telephone call and to generate a first 
50 message in response thereto; 

a home location register (HLR) coupled to the originating 
MSC, wherein the HLR is configured to receive the first 
message and to responsively retrieve one or more parts 
of the caller-specific information from the LIDB; and 
55 an intelligent peripheral (IP) coupled to the HLR, wherein 
the HLR is configured to transfer said one or more parts 
of the caller-specific information to the IP via a second 
message from the HLR to the IP, wherein the second 
message is a service request (SERVREQ) Invoke mes- 
60 sage containing therein said one or more parts of the 
caller-specific information. 

40. The system as in claim 39, wherein the IP is config- 
ured to transmit a service request return result message to the 
HLR acknowledging receipt of the SERVREQ Invoke mes- 

65 sage. 
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